could you replace this anyhow::Result<Operation> with Result<Operation, BatchError> where BatchError (or whatever it should be named) is a new type that derives thiserror::Error? example from auth https://github.com/getsentry/objectstore/blob/main/objectstore-server/src/auth/error.rs

anyhow doesn't really let us differentiate between an error that should return a 400 BAD REQUEST and an error that should return a 500. i'm not sure we should be using it at all, or at least we should push our usage of it as high as we can imo

Yeah this is something I noticed as well and that's why I wanted to move to using structured errors with thiserror instead of using anyhow https://linear.app/getsentry/issue/FS-220/improve-error-handling
It might be convenient for me to do that first, and then rebase this PR on top.

i don't think the two have to be coupled. i think you can just return Result<Operation, BatchError> and the error can be converted to anyhow::Error which can be converted to AnyhowResponse in the endpoint implementation. then this file can be left alone when doing FS-220. but up to you, it'll be done at some point either way

FromRequest requires that your Rejection impl IntoResponse, i think you can use (StatusCode, &'static str) as your Rejection and skip calling .into_response() every time?

why multier over https://docs.rs/axum/latest/axum/extract/struct.Multipart.html?

Good catch, I think we can use axum::extract::Multipart directly now.
With the old design, which included a manifest of operations as the first part, the correct content-type would've been multipart/mixed and therefore I had to use multer (which axum::extract::Multipart uses under the hood) directly because axum::extract::Multipart only works with multipart/form-data 😅.
Now multipart/form-data is correct, so we can move to using axum::extract::Multipart directly.